Add FilterRestrictions annotation transform to managedDevice entity type - #1194
Conversation
The entity description says filtering is only supported on a subset of properties, but there was no FilterRestrictions annotation, so the metadata advertised the whole collection as filterable. Lists the 35 properties that are not filterable in either v1.0 or beta. The two that are filterable in beta only, deviceType and ownerType, are left out so the same annotation stays correct for both versions.
|
@microsoft-github-policy-service agree |
Egor Sidorenko (esidorenko-sl)
changed the title
managedDevice entity type
|
I got access to a tenant with Intune and checked what the service actually does. It rejects the undocumented properties outright rather than ignoring them, which lines up with the annotation being the missing piece. Requests against
So the service knows exactly which properties can be filtered and says so at request parse time, before it looks at any data. The tenant I used has no enrolled devices, which does not matter for the 400 cases since the query never gets that far. This is the same behaviour that #225 described for |
There was a problem hiding this comment.
Pull request overview
Adds a CSDL preprocessing transform so microsoft.graph.managedDevice gets an explicit Org.OData.Capabilities.V1.FilterRestrictions annotation with a NonFilterableProperties list, aligning the metadata’s machine-readable capabilities with the type/property descriptions and improving generated client behavior.
Changes:
- Added a new XSLT named template to emit
FilterRestrictionsformanagedDevice, including a hard-codedNonFilterablePropertiescollection. - Added transform call sites to (a) create
Annotations Target="microsoft.graph.managedDevice"when absent and (b) append the annotation when the target already exists. - Updated the preprocess transform golden test input/output to cover the “target already exists” path and verify emitted annotation content.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| transforms/csdl/preprocess_csdl.xsl | Introduces the managedDevice FilterRestrictions emit logic and integrates it into the preprocess transform flow. |
| transforms/csdl/preprocess_csdl_test_input.xml | Adds a managedDevice type-level Annotations node to exercise the “existing target” transform path. |
| transforms/csdl/preprocess_csdl_test_output.xml | Updates expected output to include the new FilterRestrictions annotation and property list. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| <xsl:template match="edm:Schema[@Namespace='microsoft.graph']/edm:Annotations[@Target='microsoft.graph.managedDevice']"> | ||
| <xsl:copy> | ||
| <xsl:copy-of select="@*|node()"/> | ||
| <xsl:call-template name="ManagedDeviceFilterRestrictionsTemplate"/> | ||
| </xsl:copy> | ||
| </xsl:template> |
Fixes #1193
microsoft.graph.managedDevicecarries a description saying that$filteris only supported on some of its properties, but it has noFilterRestrictionsannotation. With the annotation missing,Filterabledefaults to true and the metadata tells every generated client that the whole collection can be filtered.This adds the annotation, following the same approach as #227 for
directorySetting.What the change does
transforms/csdl/preprocess_csdl.xslgets a new named templateManagedDeviceFilterRestrictionsTemplatethat emitsFilterabletrue plus aNonFilterablePropertiescollection, and two call sites mirroring thedirectorySettingones. One handles the case whereAnnotations Target="microsoft.graph.managedDevice"already exists, which is what happens in both v1.0 and beta today, and the other creates the element if it is ever absent.I did not reuse the existing
FilterRestrictionsTemplatebecause it only emits theFilterableflag and there is no way to pass it a property list.How the property list was built
I took the list from the metadata itself rather than from the API docs. A property counts as filterable if its own
Core.V1.Descriptionmentions$filter, which is exactly the rule the entity description states.v1.0 has 55 properties, 20 of them filterable. Beta has 83 properties, 22 filterable, the two extra ones being
deviceTypeandownerType. The 35 properties listed inNonFilterablePropertiesare the ones that are not filterable in either version, so the same annotation is correct for v1.0 and beta.deviceTypeandownerTypeare deliberately left out for that reason.For reference, the 20 properties documented as filterable in v1.0 are
azureADDeviceId,complianceGracePeriodExpirationDateTime,complianceState,deviceCategoryDisplayName,deviceName,emailAddress,enrolledDateTime,exchangeAccessState,imei,jailBroken,lastSyncDateTime,managementAgent,managementState,manufacturer,model,operatingSystem,osVersion,phoneNumber,serialNumberanduserPrincipalName.Testing
I added a type level
Annotationselement formanagedDevicetopreprocess_csdl_test_input.xmlso the test exercises the same path that runs against the real schema, then regeneratedpreprocess_csdl_test_output.xmlwithtransform.ps1. The output keeps the existing description and appends the new annotation with all 35 property paths. No other part of the output changed.One note on the
directorySettingtemplate I copied from: it sets an attribute after copying child nodes, which XSLT ignores at that point. I left that out of the new template since@*|node()already copies the target attribute.Happy to adjust the property list, or to redo this through
additions/main.tspinstead if you would rather have new capability annotations go that route.